[Claude Code 🤖] The open question for an expression index like this is whether the planner still reaches it inside the full query the engine emits — an isolated EXPLAIN on the bare predicate doesn't prove that. Some context on why that's a real concern here, and the verification result:

What the engine actually emits. A type filter never appears as a single containment predicate. typeCondition in packages/runtime-common/index-query-engine.ts expands one card ref into an OR of containment arms — one per equivalent spelling of the type key (internalKeysFor: RRI form, real-URL form, virtual-alias form) — and _search ANDs that with i.realm_url = $n, the is_deleted check, i.type = $n, and a not-errored predicate that references the LEFT-JOINed prerendered_html row. Plural-path field filters additionally splice CROSS JOIN LATERAL jsonb_tree(...) into the FROM clause, and everything runs under GROUP BY i.url, i.type + ORDER BY ... LIMIT. Any of those wrappers could in principle keep the qual from being pushed into the scan of i.

Verified against a real indexed dataset (13.5k rows / 23 realms, Postgres 16.3), running the full emitted _search shape rather than the bare predicate. The planner pushes the whole OR into the scan as a BitmapOr over this index, and BitmapAnds it with the realm/type btree:

Bitmap Heap Scan on boxel_index i  (actual rows=659)
  Recheck Cond: ((COALESCE(types,'[]'::jsonb) @> '["<url form>"]' OR
                  COALESCE(types,'[]'::jsonb) @> '["<rri form>"]')
                 AND realm_url = $realm AND type = 'instance')
  ->  BitmapAnd
        ->  BitmapOr
              ->  Bitmap Index Scan on boxel_index_types_containment_idx (rows=659)
              ->  Bitmap Index Scan on boxel_index_types_containment_idx (rows=0)
        ->  Bitmap Index Scan on boxel_index_realm_url_type_index (rows=1186)

The same holds in the three variations that could have defeated it:

• Generic plan with bind parameters (EXPLAIN (GENERIC_PLAN) with $n placeholders — the extended-protocol worst case, relevant because node-postgres sends parameterized statements): index cond binds COALESCE(types, '[]'::jsonb) @> $3 directly.
• With a jsonb_tree lateral join present (a plural-path eq alongside the type filter): the containment qual still lands in the scan of i, before the lateral fan-out.
• The hasFileType / hasInstanceType SELECT 1 ... LIMIT 1 shape: index-served, sub-ms.

And the before-state confirms the premise for dropping the bare-column indexes: with only boxel_index_types_index present, the planner scans via the realm/type btree and evaluates the containment row-by-row as a post-scan filter (Rows Removed by Filter: 527) — the bare GIN never appears in any plan.

One boundary worth knowing: the index only helps where the containment sits in an AND chain over i columns. A type condition nested under a filter-level any: whose sibling branch references a json_tree alias becomes an OR spanning the lateral join, which no index can serve — that's inherent to OR-across-a-join, and the dominant shapes (the on type anchor and card-type filters, which are always AND-ed) are the ones served.

For background on why no query-side change is needed here (unlike the singular string eq filter, which had to be rewritten from search_doc -> 'a' ->> 'b' = $n extraction into the JsonContains search_doc @> '{...}'::jsonb containment node to become GIN-servable): GIN jsonb opclasses serve @>, and field-extraction predicates are not GIN-servable at all. The types predicate is already containment-shaped — the only mismatch was on the index side, which this migration fixes.

[Claude Code 🤖] jsonb_path_ops is the right call for this predicate, and it's worth spelling out the two capabilities it trades away so a future change on this column knows when the choice stops fitting:

1. It serves only @>. The key-exists operators (?, ?|, ?&) and everything else in the default jsonb_ops repertoire are unsupported. The types-contains predicate is pure containment, so nothing is lost — but a future filter wanting e.g. "does any type key start with…" or key-existence semantics would need a jsonb_ops index (or a different structure entirely).
2. It produces no index entries for empty arrays/objects. Rows whose types is NULL index as '[]' under the COALESCE and therefore have no entries — which is exactly right: they can never satisfy a containment test against a non-empty right-hand side, and the engine always binds a one-element array ('["<key>"]'), never an empty one. The degenerate @> '[]' query (true for every row, answerable only by a full index scan) is not a shape the engine can emit.

Nothing to change — this is confirmation that both trade-offs are safe for the emitted predicate, plus the conditions under which they'd stop being safe.

[Claude Code 🤖] Verified the restore fidelity: the referenced migrations create these via pgm.createIndex(table, 'types', { method: 'gin' }), whose auto-generated names are exactly boxel_index_types_index / boxel_index_working_types_index with the default jsonb_ops opclass on the bare column — which is what's recreated here, so their down()s (pgm.dropIndex(table, 'types')) resolve by name. 👍

One wording nit while you're in here: "still find them" is relative-time phrasing — the comment reads cleaner as a timeless contract, e.g. "…so the down migrations of 1735668047598 and 1735832183444 find them by name." (Referencing migrations by timestamp is fine — they're immutable filenames in this directory, unlike tracker or PR numbers, which don't belong in comments.)

[Claude Code 🤖] Good — this comment is the guard that keeps the two sides of the contract from drifting, since nothing executable enforces the coupling. One clarification worth folding in: "matches it verbatim" slightly overstates the strictness, and knowing where the real line sits helps a future editor judge what's safe.

The planner matches on the parsed expression tree, not the SQL text. So these are all fine and don't break index use:

• the alias qualification (i.types here vs. bare types in the index DDL),
• whitespace, keyword case, COALESCE vs coalesce,
• the right-hand side of @> (it's the query value — only the left operand must match the indexed expression).

What does break it is any semantic change to the left operand's tree: a different empty-array placeholder ('{}'::jsonb), an added cast, or restructuring into types IS NOT NULL AND types @> …. The failure mode is silent — queries stay correct, they just fall back to evaluating containment row-by-row behind the realm/type btree.

Suggested tweak: "…Postgres only uses an expression index when the query's left operand structurally matches the indexed expression (aliasing and whitespace don't matter; any semantic change to the COALESCE wrapper does), so changing the SQL here un-indexes type filters unless the index expression moves with it."

[Claude Code 🤖] For anyone wondering whether deleting this file (rather than just adding the renamed one) is correct: yes, on two grounds.

1. pnpm make-schema (packages/postgres/scripts/schema-dump.sh) starts by removing every *_schema.sql in this directory before writing the fresh dump — the generator's contract is exactly one file, so two sitting side-by-side on the base branch is leftover state that this regeneration converges.
2. The rename itself is load-bearing, not churn: getLatestSchemaFile() in packages/host/config/environment.js throws in dev/test builds when the newest schema file's timestamp prefix doesn't match the newest migration's — so every new migration must ship with a regenerated schema file, even an index-only one.

The content coming out unchanged (100%-similarity rename) is expected: the SQLite converter emits tables only, no indexes. The client-side SQLite path evaluates the types predicate as a json_each EXISTS with no index either way, so this PR's behavior change is Postgres-only by construction.